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Abstract 

In  2001,  the  Defense  Medical  Logistics  Standard  Support  System  (DMLSS) 
Release  3.0  was  deployed  to  Moncrief  Army  Community  Hospital,  the  Army’s  test  site. 
The  goal  of  this  project  was  to  examine  whether  the  deployment  was  done  in  an  effective 
manner.  Through  a  literature  review,  examination  of  organizational  documents,  and 
interviews  with  personnel  at  the  United  States  Army  Medical  Information  System 
Support  Agency  (USAMISSA)  in  San  Antonio,  Texas,  the  DMLSS  Program  Office  in 
Falls  Church,  Virginia,  the  Joint  Medical  Logistics  Functional  Development  Center 
(JMLFDC)  in  Fort  Dietrick,  Maryland,  and  Moncrief  Army  Community  Hospital 
(MACH)  in  Fort  Jackson,  South  Carolina,  I  was  able  to  show  that  the  deployment  process 
for  Release  3.0  was  well  conducted. 

The  MACH  logistical  staff  was  mentally  prepared  for  the  change  in  computer 
systems.  The  staff  received  briefings  from  MACH  leadership,  senior  Medical  Command 
representatives,  and  JMLFDC  staff  prior  to  the  actual  deployment.  Since  the  staff 
understood  the  system  and  its  capabilities,  the  implementation  of  was  DMLSS  rapid  and 
thorough. 

The  training  did  have  areas  that  could  have  been  improved.  There  were  problems 
during  the  classroom  week  with  class  scheduling  and  training  computer  capabilities,  but 
the  on-the-job  training  conducted  by  the  deployment  staff  paid  great  dividends  and 
enabled  MACH  to  fully  utilize  DMLSS  when  the  old  systems  were  turned  off 

Implementation  of  DMLSS  was  well  planned  and  executed  but  needed  some 


refinement.  The  site  visit  made  by  that  the  JMLFDC  staff  enabled  the  system’s  hardware 
requirements  to  be  identified  and  equipment  to  be  ordered.  The  majority  of  the  data 
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conversion  of  old  files  was  accurate  but  some  adjusting  of  the  new  database  had  to  be 
done  during  the  deployment. 

Although  MACH  was  the  Army’s  test  site  for  the  deployment,  the  DMLSS 
system  was  up  and  running  at  the  end  of  the  three  week  deployment.  While  problems  did 
arise  that  required  alterations  to  the  deployment  plan  and  changes  to  the  DMLSS  program 
itself,  the  deployment  was  effective.  The  lessons  learned  at  MACH  were  incorporated 
into  the  deployment  plan  of  the  DMLSS  Program  Office  and  should  make  future 
deployments  even  better. 
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Defense  Medieal  Logistics  Standard  Support  (DMLSS)  System; 

A  Case  Study  of  the  Deployment  of  DMLSS  Release  3.0  at  Moncrief  Army  Community  Hospital 

Introduction 

Overview  of  Moncrief  Army  Community  Hospital  (MACH) 

Moncrief  Army  Community  Hospital  (MACH)  is  a  medical  complex,  which 
includes  a  12  story  main  facility  and  four  outlying  buildings.  MACH  serves  60,500 
beneficiaries  at  Fort  Jackson  and  greater  Columbia,  South  Carolina.  It  is  part  of  the 
Southeast  Region  of  the  Army  Medical  Department  with  Regional  Headquarters  located 
at  Eisenhower  Medical  Center,  Fort  Gordon,  in  Augusta,  Georgia.  There  are  786  staff 
members  at  MACH,  395  military  and  391  civilian.  They  provide  specialty  care  in  family 
practice,  dermatology,  mental  health,  optometry,  gynecology,  and  orthopedic  surgery. 

The  daily  census  for  inpatients,  including  psychiatric  patients,  is  17.  Each  day  1,253 
people  are  seen  in  the  clinics,  1,032  lab  procedures  are  conducted,  1,794  prescriptions  are 
fdled,  and  317  x-rays  are  produced.  The  Logistics  Division  has  assigned  to  it  78  officers, 
soldiers,  and  civilians.  It  consists  of  the  following  sections:  Office  of  the  Chief  of 
Logistics,  Supply  and  Acquisition,  Medical  Maintenance,  Property  Management,  and 
Facility  Maintenance.  Each  of  these  sections  utilizes  the  Defense  Medical  Eogistics 
Standard  Support  (DMESS)  System,  in  one  form  or  another,  to  complete  its  respective 
missions. 

Statement  of  the  Issue  Investigated 

The  issue  to  be  investigated  was:  Was  the  Defense  Medical  Eogistics  Standard 
Support  (DMESS)  System  fielded  in  an  effective  manner  at  MACH?  To  determine  that, 
the  following  questions  must  be  addressed:  Were  the  Eogistics  Division  personnel 
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mentally  prepared  to  aeeept  the  new  system?  Was  the  system  implemented  so  as  to 
conform  to  Fort  Jackson  business  practices?  Did  personnel  receive  proper  instructions  on 
operating  the  new  system?  How  were  problems  with  the  system  addressed  and 
corrected?  By  answering  these  questions  it  is  hoped  that  improvements  can  be  made  in 
the  process  of  deploying  DMLSS  to  the  rest  of  the  Army. 

Brief  History  of  the  DMLSS  System 

Military  medical  logistics  was  described  in  1990  as  having  a  “just  in  case” 
management  philosophy.  The  basic  element  was  the  storage  of  large  amounts  of  materiel 
at  Department  of  Defense  (DoD)  locations,  either  wholesale  depots  or  military  treatment 
facilities  (MTFs).  The  depots  existed  to  support  immediate  requirements,  like 
deployments,  as  well  as  daily  demand  at  the  DoD  MTFs.  Large  inventories  were 
maintained  at  the  MTFs  to  ensure  health  care  services  occurred  without  interruption. 
These  practices  reflected  a  lack  of  confidence  in  the  medical  supply  processes  which 
were  characterized  by  long  order  shipment  times  from  depots  to  MTFs.  While  MTFs 
typically  ordered  materiel  from  the  depots,  in  some  cases,  they  ordered  directly  from 
civilian  companies.  No  automated  product  or  price  comparison  tool  was  available  to 
facilitate  best  value  procurement,  and  each  of  the  DoD  services  (Army,  Navy  and  Air 
Force)  had  its  own  automated  information  system  (AIS)  for  medical  logistics.  One 
service  was  not  able  to  interface  or  integrate  with  another’s  AIS  (Wolfe,  2002).  Not  only 
was  this  an  inefficient  way  of  doing  business,  it  was  also  expensive.  Walter  Reed 
Medical  Center  in  Washington,  District  of  Columbia,  had  10  warehouses  containing  6 
months  worth  of  medical  supplies.  All  of  the  drugs  could  not  be  used,  so  up  to  $50,000 
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worth  of  expired  materiel  was  destroyed  a  month  (Duvall,  2003).  A  new  way  of  doing 
business  was  needed,  and  its  motto  would  be  “just  in  time”  logisties  (Friel,  2002). 

In  April  of  1990,  a  meeting  was  held  between  representatives  of  Army,  Navy  and 
Air  Foree  medical  logistics  communities  at  the  request  of  the  Assistant  Secretary  of 
Defense  (Health  Affairs)  and  the  Deputy  Undersecretary  of  Defense  (Logistics).  These 
officers  were  instructed  to  look  10  years  in  the  future  and  see  where  DoD  medical 
logistics  should  be.  The  officers  looked  to  the  civilian  community  for  ideas.  They  found 
that  Johnson  &  Johnson  was  able  to  fill  orders  in  24  hours,  while  the  DoD  required  3  to  4 
days  to  fill  orders  for  its  highest  priority  items.  A  Department  of  Veterans  Affairs  (VA) 
facility  in  Hines,  Illinois  (which  received  its  supplies  from  a  DoD  depot  located  on  the 
VA  facilities  campus),  had  a  4  day  fill-time  for  its  pharmacy  supplies.  Logisticians  there 
switched  to  a  civilian  supplier  located  100  miles  away  and  started  receiving  supplies  in 
24  hours.  They  also  found  that  DoD  only  used  4%  of  the  medical  supplies  used  in  the 
nation.  This  disproved  the  argument  that  the  large  stockpiles  at  depots  were  needed  for 
contingency  operations;  there  were  already  enough  supplies  in  the  civilian  inventories  to 
fill  DoD’s  requirements  (Duvall,  2003).  The  group’s  ideas  were  taken  back  to  the  three 
services  for  further  study.  Then,  in  August  1990,  the  Gulf  War  deployments  began. 

It  was  the  Gulf  War  that  drove  home  the  need  for  changes.  It  provided  dramatic 
demonstrations  of  the  system’s  inefficiencies.  There  was  no  integrated  communications 
channel  relaying  needs  throughout  the  theater,  there  were  “stove  pipe”  systems  (the 
Army’s  Theater  Army  Medical  Materiel  Information  System  [TAMMIS]  and  the  Air 
Force’s  Medical  Logistics  System  [MEDLOG])  that  were  uncoordinated  and  multi- 
channeled  (Wolfe,  2002).  Only  the  Army’s  (TAMMIS)  could  be  used  for  inventory 
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management  in  the  field.  None  of  the  services  could  order  electronically  (Duvall,  2003). 
These  problems  led  to  waste.  There  was  unnecessary  duplication  in  stockpiling  and 
improper  utilization  of  transportation  assets,  such  as  trucks  and  planes.  While  the 
logistical  mission  was  successfully  accomplished  in  the  war,  it  was  done  at  great  expense 
and  showed  a  glaring  need  for  improvement. 

With  the  findings  of  the  April  1990  meeting  and  the  lessons  learned  in  the  Gulf 
War  as  the  driving  forces,  the  Assistant  Secretary  of  Defense  (Health  Affairs)  and  the 
Deputy  Undersecretary  of  Defense  (Logistics)  directed  “the  Military  Medical  Logistics 
community  to  develop  a  Tri-Service  . . .  [AIS]  to  be  used  in  peace  and  war”  (Aitkin, 

1996),  that  is,  in  fixed  facilities  and  in  field  units.  The  Defense  Medical  Logistics 
Standard  Support  (DMLSS)  Program  was  created.  It  was  headquartered  in  Falls  Church, 
Virginia  and  had  the  following  objectives: 

Create  an  integrated  medical  supply  activity  at  the  DoD  level; 

Reduce  the  costs  of  pharmaceuticals  and  medical/surgical  items; 

Reduce  order  shipment  time  for  pharmaceuticals  and  medical/surgical  items; 

Reduce  inventory  at  wholesale  (depot)  and  retail  (MTF)  levels; 

Reduce  the  time  health  care  providers  spend  on  medical  logistics  related  activities;  and 

Incorporate  best  business  practices  of  the  commercial  health  care  industry 

To  meet  these  objectives,  the  DMLSS  Program  Office  would  develop  two 
separate,  but  integrated,  projects.  They  were  initiating  the  “prime  vender”  program  and 
developing  the  DMLSS  software. 

First,  it  was  understood  early  on  that  it  would  take  years  to  develop  an  automated 
information  system  that  would  incorporate  the  business  practices  of  three  separate 


Case  Study  of  the  DMLSS  Deployment  12 


military  departments  and  provide  full  electronic  commerce  capabilities.  So  it  was 
decided  to  adopt  a  prime  vendor  program  as  a  way  to  make  a  quick  and  significant 
change  in  the  costs  of  doing  business  (Wolfe,  2002).  (“A  prime  vendor  is  a  contractor 
that  is  given  the  responsibility  to  manage,  store,  and  distribute  inventory  or  to  manage 
and  perform  services  or  research  on  a  recurring,  frequent  basis  upon  request  of  [DoD] 
users”  [Korody-Colwell  and  Zucker,  2001].)  It  was  modeled  after  the  Vanderbilt 
Medical  Center’s  prime  vendor  contract  with  Baxter  Pharmaceuticals,  Inc.,  which 
enabled  it  to  achieve  24-hour  turn  around  for  its  medical  surgical  supplies  (Duvall,  2003). 
So,  test  sites  were  set  up  at  three  DoD  medical  centers  and  three  smaller  hospitals.  The 
results  were  dramatic  and  positive. 

Walter  Reed  reduced  its  10  warehouses  to  2,  its  cost  of  the  supplies  destroyed 
each  month  went  from  $50,000  to  under  $500,  its  supplies  on  hand  shrunk  from  6 
months’  worth  to  2-3  days’  with  24  hours  as  the  new  standard  for  resupply  from  the 
civilian  contractor  or  the  DoD  supply  center  located  in  Philadelphia.  Previously  60%  of 
the  dollars  spent  were  on  local  purchases  that  could  not  wait  on  resupply  from  the  depot. 
Since  there  was  no  credit  card  system  at  the  time,  this  led  to  large  contracting  staffs.  The 
prime  vendor  initiatives  enabled  MTFs  to  greatly  reduce  the  number  of  contracting 
positions  (Duvall,  2003).  In  time,  the  program  was  expanded  to  all  DoD  facilities  and 
has  saved  hundreds  of  millions  of  dollars  with  no  deficiencies  in  operational  readiness 
noted.  For  the  period  fiscal  year  (FY)  1992  to  FY  1996,  a  $154  million  reduction  in  the 
cost  of  drugs,  a  $409  million  reduction  in  inventories  at  the  depots,  and  an  $84  million 
reduction  in  supplies  stored  at  the  MTFs  were  achieved  (Wolfe,  2002).  It  was  the  savings 
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from  the  prime  vendor  program  that  funded  the  development  of  DMLSS  throughout  the 
budget  restrieted  1990s  (Duvall,  2003). 

The  second  project  was  the  development  of  the  Tri-Service  AIS,  called  the 
DMLSS  System,  to  replace  13  systems  currently  in  use  within  DoD.  It  would  be  broken 
down  into  four  sections  that  would,  for  the  first  time,  enable  medical  logistics  to  be 
managed  out  of  one  Windows  ™  based  automated  information  system.  The  sections 
were  Materiel,  Facilities,  Equipment  &  Technology  Management,  and  Wholesale 
Functions.  Electronic  Data  Systems  was  hired  as  the  contractor  to  write  the  programs  at 
the  new  Joint  Medical  Eogistics  Functional  Development  Center  (JMEFDC)  located  at 
Fort  Dietrick,  Maryland.  There  military  experts  (officers,  non-commissioned  officers, 
warrant  officers  and  military  retirees)  would  work  with  the  contractor  to  create  DMFSS. 
The  functional  area  experts  (e.g.,  a  medical  maintenance  chief  warrant  officer)  create 
documents  outlining  requirements  and  specifications,  i.e.,  what  the  program  must  be  able 
to  do.  These  documents  would  be  blended  together  for  the  three  services,  and  the 
programmers  would  write  the  code  that  created  the  software.  This  would  be  constantly 
reviewed  and  improved  until  a  working  program  was  created  (Burrhus,  2003). 

Using  DMFSS,  logistics  divisions  can  electronically  manage  their  inventory, 
order  supplies,  pay  bills,  track  maintenance  schedules,  track  property,  place  work  orders, 
and  build  management  reports.  The  inventories  are  done  with  hand  held  barcode  readers 
that  download  the  information  into  DMFSS  docking  stations.  The  system  is  linked  with 
the  Defense  Finance  and  Accounting  System  (DFAS)  so  bills  are  forwarded  from  the 
supplier,  through  DMFSS,  to  DFAS;  and  money  is  sent  to  a  supplier’s  account  without 
paperwork  being  needed.  The  speed  of  payment  also  makes  doing  business  with  the 
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government  mueh  more  attraetive  to  eivilian  firms.  Work  orders  are  submitted  through 
DMLSS  from  employees’  desktop  personal  computers;  no  longer  will  phone  calls  need  to 
be  made  or  paper  forms  filled  out.  DMLSS  is  an  all-encompassing  medical  logistics 
system  that  has  no  counterpart  in  the  civilian  sector  (Duvall,  2003).  Coupled  with  prime 
vendor  contracting,  it  has  been  so  successful  that  it  has  received  numerous  awards.  It 
earned  the  DoD  Electronic  Commerce  Pioneer  Award  in  1999  for  “an  electronic 
commerce  initiative  that  pushes  the  current  state  of  electronic  commerce  to  reduce  an 
antiquated  paradigm  and  demonstrates  a  high  level  of  innovation  and  government 
creativity”  (Johnson,  1999).  In  2002,  DMLSS  received  the  DoD  Business  Solutions  in 
the  Public  Interest  Award  for  “combining  several  older  computer  systems  and  paper- 
based  processes  into  a  single  online  management  tool”  (Friel,  2002).  It  has  shown  its 
value  to  DoD. 

Since  combining  the  systems  being  used  by  the  three  different  services  and 
beginning  entirely  new  business  practices  would  take  years,  DMLSS  development  was 
planned  to  be  done  in  stages  and  the  deployment  of  the  newly  developed  technology 
would  be  in  three  releases  (Wolfe,  2002).  Release  1.0  took  place  throughout  DoD 
starting  in  1996.  It  provided  Facility  Maintenance  and  Customer  Support  modules  that 
contained  product  and  price  comparison  tools  and  critical  facility  management  functions 
previously  done  manually  (Clarke,  1997).  Release  2.0  was  in  1998.  It  contained  the 
Customer  Area  Inventory  Management  module  and  a  second  increment  of  the  Facility 
Maintenance  module.  Hand-held,  wireless,  bar  code  devices  were  used  to  control 
receipts  and  inventories.  It  also  contains  a  streamlined  DFAS  and  electronic  commerce 
interface  (Clarke,  1997).  Release  3.0  was  begun  in  2001,  and  the  Army’s  test  site  was 
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MACH.  This  release  contained  the  final  part  of  Materiel  Management  and  the 
Equipment  &  Technology  Management  module.  It  included  “the  full  suite  of  medical 
logistics  capabilities  to  include  stock  fund  level  inventory  management,  quality  control, 
medical  technology  management,  and  management  of  readiness  materiel”  (DMLSS 
Handout,  2002).  Release  3.0,  “Enable[d]  the  services  to  turn  off  service  unique  medical 
logistics  legacy  systems  such  as  TAMMIS,  AMEDDPAS,  and  MEDLOG”  (Burrhus, 
2003). 

So  how  did  these  deployments  take  place?  How  were  they  organized?  Who  did 
the  training?  Was  the  system  “sold”  to  the  staff  before  introduced?  Were  the  MTEs 
included  in  the  planning?  Who  paid  for  the  installation  and  training?  When  were  the  old 
systems  discontinued?  Did  the  deployment  of  DMLSS  conform  to  the  professional 
literature  dealing  with  implementation  of  new  automated  information  systems? 

Literature  Review 

Organizational  Change 

“Organizational  change”  is  defined  as  “a  continuous  process  that  involves 
multiple  and  often  incomplete  transactions  and  uncertain  future  states  that  lead 
organizations  to  transition  from  one  state  to  another  (Eried  and  Johnson,  2001).” 
Changing  the  way  an  organization  does  business  and  replacing  the  tools  that  it  uses  to  do 
its  job  is  a  difficult  task.  The  implementation  of  prime  vendor  contracting  and  DMLSS  at 
MACH  were  dramatic  organizational  changes.  How  should  they  have  been  handled? 

Author  Sharon  Topping  states,  “Change  has  become  a  way  of  life  in  most 
healthcare  organizations.  Many  believe  that  to  withstand  profound  change,  organizations 
must  be  flexible  with  loose  boundaries  and  the  ability  to  adapt  and  respond  to  the 
environment  and  its  stakeholders  (both  internal  and  external).  Therefore,  change  is  the 
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greatest  problem  that  healthcare  executives  have  to  face  in  their  roles  as  managers  and 
decision  makers”  (Fried  and  Johnson,  2001). 

Change  takes  many  forms,  from  revolutionary  to  incremental.  “Revolutionary 
change”  is  a  complete  reversal  of  an  organization’s  direction  that  involves  a 
transformation  of  the  structure,  culture,  and  strategy.  “Incremental  change”  is  a  series  of 
small  steps  that  represent  adjustments  to  environmental  changes  or  fine  tuning  of  the 
direction  of  an  organization.  A  period  of  ferment  is  a  time  period  in  which  organizations 
test  new  responses  to  the  environment  by  making  incremental  changes  (Fried  and 
Johnson,  2001).  Fitting  an  organization’s  culture  to  one  of  these  change  strategies  is  a 
key  to  implementing  change. 

Many  people  in  the  organization  will  see  the  change  as  an  opportunity,  while 
others  will  see  it  as  a  disruption  and  a  threat.  How  people  view  change  often  depends  on 
whether  they  helped  to  create  the  change  or  will  merely  be  affected  by  it.  Many 
employees  have  a  vested  interest  in  maintaining  the  status  quo.  Because  of  this  they  will 
work  actively  or  passively  to  block  change.  They  can  often  become  forces  of  inertia  that 
obscure  threats  and  create  resistance  to  change  in  organizations.  Such  resistance  can  lead 
to  failure  of  change  if  not  properly  managed.  It  is  the  fear  of  uncertainty  that  causes 
many  staff  members  to  view  change  as  a  loss  of  control  and  a  threat  to  their  jobs. 
Additional  roadblocks  that  can  serve  as  barriers  to  organizational  change  include: 
bureaucratic  hierarchy  and  administrative  systems,  organizational  culture,  organizational 
history,  organizational  size  and  age,  and  lack  of  resources  (Freid,  2001).  Each  of  these 
roadblocks  must  be  managed,  i.e.,  the  “change  agent”  that  is  seeking  to  facilitate  the 
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ehanges  must  overcome  each  of  them  because  a  single  roadblock  can  derail  the  change 
process. 

Dr.  Topping  suggested  that  focusing  on  the  human  resources  aspect  of  change 
management  is  a  key  to  success.  Encouraging  open  communication  between  employees 
and  management  is  important.  People  must  feel  they  can  express  their  opinions  and 
concerns  without  repercussions.  When  openness  is  established  done  early  in  the  planning 
process,  acceptance  of  the  change  goes  more  smoothly.  She  also  suggests  winning  over 
internal  and  external  stakeholders.  These  power  groups  may  include  white  collar  and 
blue-collar  employees,  federal  agencies,  or  consumer  groups.  The  use  of  a  “champion”  is 
a  key  to  persuading  the  stakeholders.  Champions  are  prominent  or  well  respected 
members  of  the  group  that  have  influence  over  other  members.  Convert  them  to  your 
side,  and  they  can  bring  others  with  them.  Another  method  is  building  teams  that  assist 
in  the  planning  and  implementation  of  the  change.  By  using  teams,  you  involve 
employees  in  the  process,  which  allows  them  to  prepare  psychologically  for  the  change. 
Some  resistance  to  organizational  change  is  inevitable,  so  accommodating  it  should  be 
part  of  the  implementation  plan  from  the  beginning  (Fried  and  Johnson,  2001). 

Ginter,  Swayne,  and  Duncan  discuss  developing  organizations  that  embrace 
change  by  building  an  adaptive  culture,  i.e.,  “. . .  one  that  allows  for  reasonable  risk 
taking,  builds  on  trust  and  has  a  willingness  to  allow  people  to  fail,  and  exhibits 
leadership  at  all  levels.”  In  an  organization  with  an  adaptive  culture,  everyone,  regardless 
of  position,  is  encouraged  to  initiate  changes  that  are  in  the  best  interest  of  customers, 
employees,  and  managers.  The  fear  of  failure  is  reduced  by  tolerating  creative  efforts  to 
make  the  organization  a  better  place  to  work  and  more  responsive  to  stakeholders.  The 
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authors  believe  that  an  adaptive  eulture  must  already  be  in  plaee  before  ehanges  to  the 
organization  can  happen.  In  fact,  it  should  be  in  place  before  changes  are  planned.  They 
specifically  mention  information  technology  as  an  area  where  people  need  to  be  willing 
to  adapt  because  of  the  need  to  frequently  upgrade  and  replace  hardware  and  software. 
Employees  must  trust  that  their  managers  will  be  seeking  more  efficient  and  cost 
effective  products  that  will  not  hinder  their  ability  to  do  their  jobs,  but  will  enhance  it.  A 
free  flow  of  information  that  builds  understanding  and  acceptance  is  a  key  to  creating  this 
adaptive  culture  (Ginter  et  ah,  1998). 

Organizational  change  is  introduced  in  Longest,  Rakich,  and  Darr’s  book  with  the 
following  quotation,  “Change  is  inevitable  and  the  future  is  uncertain.”  To  them 
organizational  changes  are  made  because  managers  perceive  a  performance  deficiency  in 
their  areas  of  responsibility.  To  address  this  deficiency,  managers  must  understand  how 
to  be  change  agents. 

Longest,  Rakish,  and  Darr  break  the  management  of  change  down  into  tasks. 

Each  task  must  be  successfully  accomplished  before  an  organization  can  move  onto  the 
next  one.  The  first  task  is  for  managers  to  recognize  situations  that  require  an 
organizational  change.  Then,  they  must  identify  the  nature  of  the  change  needed.  These 
two  tasks  are  related  and  can  be  triggered  by  various  pressures  for  change,  such  as 
improvements  in  technology. 

Once  the  nature  of  the  change  is  identified,  steps  must  be  taken  to  ensure  effective 
planning  for  implementation.  These  steps  include:  developing  alternative  changes  to  be 
considered;  choosing  the  alternative  to  be  implemented;  shaping  a  general  approach  to 
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making  the  change;  and  developing  the  techniques  to  build  support  for  the  change  and 
minimize  resistance  to  it. 

The  implementation  of  an  organizational  change  is  accomplished  through  three 
additional  tasks:  unfreezing  the  status  quo;  introducing  the  change;  and  refreezing  the 
organizational  change.  First,  managers  must  disrupt  the  status  quo  and  prepare  those 
involved  for  change.  Then  they  must  insert  some  concept,  practice,  or  thing  into  a 
situation  to  modify  the  organization’s  purpose,  culture,  tasks,  technologies,  personnel  or 
structure.  Lastly,  managers  must  refreeze  the  organizational  situation  in  its  new  form  to 
provide  stability  and  durability  of  the  change  in  the  organization. 

The  management  of  organizational  change  does  not  end  with  implementation. 
Managers  who  have  the  most  success  evaluate  the  results  of  change  and  use  the 
information  obtained  to  continue  improvements.  The  tasks  are  to  compare  results  with 
what  was  planned,  to  explore  the  reasons  for  differences,  and  to  use  this  information  to 
inform  and  guide  future  changes. 

The  model  of  Longest,  Rakish,  and  Darr  emphasizes  that  managers’  tasks  are 
sequential.  If  any  are  skipped  or  done  poorly,  then  managers  are  not  adequately  playing 
their  important  role  as  change  agents  and  the  entire  process  is  jeopardized  (Longest  et  ah, 
2000). 

“Health  services  are  facing  continuous  and  fundamental  change.  An  expanding 
technology,  changing  consumer  expectations,  limited  resources,  and  an  unrelenting  need 
for  adaptability  challenges  our  prevailing  assumptions  of  rationality  and  predictability  in 
the  provision  of  health  services  (Shortell  and  Kaluzny,  2000).”  The  authors  stress  that 
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there  are  different  types  of  change.  Each  presents  a  different  challenge  to  those  involved 
in  the  change  process,  and  each  requires  a  different  strategy  to  overcome  it. 

“Technical  change”  is  a  modification  in  the  way  the  normal  activities  of  the 
organization  are  carried  out.  The  changes  may  vary  in  focus,  cost,  and  potential  impact 
and  include  a  range  of  modifications  in  tasks  and  alterations  in  structure,  such  as  new 
computerized  patient  records  or  new  clinical  protocols.  While  these  changes  are  being 
implemented,  routine  activities  are  carried  on.  Operations  may  be  changed  but  remain 
consistent  with  the  overall  mission  and  goals  of  the  organization.  Proper  implementation 
of  technical  changes  requires  input  from  those  intimately  involved  to  make  them 
effective. 

“Transitional  change”  focuses  on  altering  the  organizational  mission  and  goals  but 
not  the  essential  work  processes  in  the  organization.  In  these  situations,  the  technology 
and  basic  structure  are  already  in  place,  the  major  focus  is  to  change  the  mission  of  the 
organization.  These  changes  in  mission  occur  infrequently  but  are  associated  with 
increased  stress  and  trauma  since  the  missions  and  goals  of  an  organization  are  often 
identified  with  some  powerful  internal  or  external  stakeholders. 

“Transformational  change”  is  the  most  dramatic  form  of  change.  This  includes 
change  to  the  structure  and  processes  of  the  organization  and  to  the  mission  and 
objectives  that  the  organization  exists  to  fulfill.  Changing  an  outpatient  clinic  to  a  full 
service  hospital  would  be  an  example  of  this  kind  of  change.  Transformational  changes 
are  rare,  but  when  they  do  occur  they  typically  involve  a  great  deal  of  controversy. 

Shorten  and  Kaluzny  describe  four  stages  of  change:  awareness,  identification, 
implementation,  and  institutionalism.  “Awareness”  is  the  initial  stage  in  which 
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individuals  reeognize  that  there  is  a  gap  between  what  the  organization  is  currently  doing 
and  what  it  should  be  doing.  This  awareness  can  come  from  internal  or  external  sources, 
both  of  which  have  influence  over  how  the  organization  operates.  “Identification”  is  the 
second  stage,  and  it  involves  an  attempt  to  address  the  discrepancies  noted  in  the  previous 
stage.  This  may  occur  at  various  points  in  the  organization.  The  critical  challenge  is  to 
ensure  that  once  solutions  to  these  discrepancies  or  inconsistencies  are  identified,  they  are 
quickly  implemented,  which  is  the  next  stage,  “Implementation.”  The  last  stage, 
“Institutionalization,”  involves  the  integration  of  the  change  into  ongoing  activities  of  the 
organization.  Implementation  without  internalization  results  in  a  gap  between 
organizational  practice  and  evaluation,  often  manifesting  itself  in  employee  discontent 
(Shorten  and  Kaluzny,  2000). 

Successfully  dealing  with  people  and  their  concerns  is  a  key  to  facilitating  change 
according  to  Paul  Wojciak.  He  groups  people  into  categories  (Evil  Nayser,  The  Yes 
Man,  The  Moray  Eel,  and  Wendy  Whiner)  determined  by  their  attitudes  and  actions 
during  the  change  process.  By  understanding  individual  traits  in  people  you  can  better 
formulate  strategies  to  lead  them  through  change. 

The  “Evil  Naysayer”  has  something  negative  to  say  about  every  aspect  of  the 
change.  He  or  she  is  probably  a  long  time  employee  with  great  knowledge  about  the  way 
things  are  currently  done  and  fears  losing  status  in  the  organization.  Taking  the  time  to 
explain  the  importance  of  the  changes  and  how  the  new  system  works  can  make  the 
Naysayer  an  ally  in  the  process. 

The  “Yes  Man”  agrees  with  everything  you  say  but  has  no  constructive  input, 
often  because  of  a  lack  of  self-confidence.  If  managers  can  broaden  this  individual’s 


Case  Study  of  the  DMLSS  Deployment  22 

knowledge  of  the  needed  ehange  and  build  his  or  her  confidence,  they  may  have  a 
vigorous  ally  to  facilitate  the  process. 

“The  Moray  Eel”  is  a  senior  member  of  the  organization  and  one  who  generally 
chooses  to  have  limited  involvement  with  the  change  but  who  can  veto  weeks’  worth  of 
work  in  an  instant.  The  only  way  to  placate  the  Eel,  who  is  operating  out  of  ignorance 
and  fear  of  the  change,  is  to  get  him  or  her  more  involved  in  the  change  process  so  he  or 
she  has  a  stake  in  a  successful  implementation. 

“Wendy  Whiner”  is  the  person  who  says,  “I  haven’t  got  time  for  this  nonsense. 
I’ve  got  a  job  to  do.”  By  educating  Wendy  so  she  perceives  the  change  as  needed,  you 
can  break  down  her  resistance  to  the  new  way  of  doing  business.  “People  don’t  resist 
change,  they  resist  being  changed”  (Wojciak,  1997). 

The  author  ends  his  article  with  the  following  with  three  key  rules.  Eirst, 
recognize  that  no  one  likes  change  and  that  you  must  work  on  positive  ways  to  overcome 
the  resistance  that  will  be  out  there.  You  must  identify  and  recruit  change  agents  to  help 
address  the  problems  that  change  creates.  Second,  communication  is  key. 
“Communication  is  the  common  reference  point.  If  a  good,  solid  network  of 
communication  isn’t  established,  the  ability  to  both  properly  set  and  follow  up  on 
expectations  won’t  exist”  (Wojciak,  1997).  Third,  keep  the  implementation  plan  as 
simple  as  possible.  Always  remember  that  people  make  things  happen  in  an 
organization.  Without  their  clear  understanding  of  the  new  system,  and  their  desire  to 
implement  what  they  believe  is  an  improvement,  the  change  will  be  ineffective  (Wojciak, 


1997). 
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Planning  for  Change 

Austin  and  Boxerman  provide  a  description  of  the  process  they  say  must  happen 
in  the  implementation  of  a  new  automated  information  system.  This  description  provides 
a  guideline  organizational  leaders  may  use  in  planning  for  change. 

New  equipment  will  be  required  to  implement  some  systems.  If  it  is  necessary, 
the  requirement  can  range  from  complete  installation  of  a  general-purpose  computer 
network  to  the  relatively  simple  addition  of  new  workstations  to  an  existing  system. 
Whatever  the  magnitude  of  the  requirement  for  equipment,  ordering  and  installation  must 
both  be  carefully  planned.  Good  space  planning  is  always  required.  In  some  cases, 
renovation  and/or  site  preparation  will  be  required. 

For  information  systems  being  implemented  by  in-house  staff,  planning  for  the 
development  of  applications  programs  is  part  of  the  implementation  process.  However, 
most  systems  in  healthcare  organizations  use  applications  software  from  vendors.  In 
those  cases,  some  in-house  programming  may  still  be  required  to  build  interfaces  to  other 
applications  or  change  network  configurations  to  accommodate  the  new  software. 

A  task  that  is  sometimes  overlooked  in  planning  is  database  preparation  or 
modification.  Some  health  information  systems  will  require  that  one  or  more  of  the 
organization’s  data  files  be  converted  from  manual  form  to  electronic  storage  in  the 
computer.  Other  systems  may  require  modifications  to  an  existing  electronic  database  to 
make  it  compatible  with  the  new  system. 

No  health  information  system  should  be  put  into  operation  without  being 
completely  tested.  This  testing  should  be  carefully  planned  to  determine  whether  specific 
goals  and  objectives  for  the  information  system  have  been  met  and  should  cover  all 
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aspeets  of  the  new  system  in  as  realistic  an  environment  as  possible.  Elements  to  be 
tested  include  system  objectives,  computer  and  network  hardware,  software,  training  of 
operators,  accuracy  of  costs  estimates,  and  adequacy  of  system  documentation. 

The  final  aspect  of  implementation  of  a  system  is  completion  of  all 
documentation.  This  needs  to  be  included  in  the  plan  from  the  beginning  to  ensure  it  is 
carried  out.  Documentation  should  be  a  continuous  process  carried  out  during  all  phases 
of  the  system  project.  Just  before  putting  the  system  into  use,  the  project  team  should  do 
a  final  check  to  ensure  that  the  documentation  is  adequate  for  effective  maintenance  of 
the  new  system  (Austin  and  Boxerman,  1998). 

Additionally,  the  chief  executive  officer  and  other  senior  managers  must  assume 
responsibility  for  planning  and  controlling  the  development  of  effective  information 
systems  to  serve  their  organizations.  This  cannot  be  completely  delegated  to  technical 
personnel.  Delegation  can  lead  to  poor  acceptance  of  new  technology  by  managerial 
staffs  can  be  a  major  barrier  to  full  integration  of  the  system  into  the  organization  (Zelic 
et  ah,  2000).  Management  must  also  ensure  that  careful  planning  precedes  all  decisions 
on  acquisition  of  software  and  hardware  and  that  well  established  principles  and 
procedures  are  followed  in  the  analysis,  design,  and  implementation  of  systems  (Austin 
and  Boxerman,  1998). 

Training  for  Change 

A  workforce  must  be  adequately  trained  to  use  new  technology.  Without 
adequate  training,  the  new  technology  will  not  be  utilized  to  its  full  potential  and  the 
organization  will  not  get  the  greatest  possible  benefit.  Deciding  which  computer  system 
to  purchase  or  create  equates  to  only  20%  of  the  success  during  implementation,  while 
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preparing  the  workforee  to  aceept  the  new  system  and  training  your  personnel  on  its 
effective  use  accounts  for  80%.  (Bettini,  1997)  So  how  should  training  be  conducted  in 
an  organization?  When  should  it  start?  When  should  it  end?  What  makes  it  effective? 

Healthcare  organizations  are  dependent  on  individuals  to  help  them  accomplish 
their  organizational  tasks  and  goals.  James  A.  Johnson  writes  about  how  these 
individuals  range  from  those  with  little  formal  training  and  education  to  highly  skilled 
and  educated  professionals  who  are  engaged  in  very  complex  tasks  and  decision-making. 
To  maintain  quality  and  continue  improvement,  an  organization  must  have  a  training  plan 
for  its  workforce.  This  training,  whether  reinforcing  skills  personnel  already  have  or 
introducing  new  ones,  is  what  keeps  a  modem  healthcare  organization  viable  and 
competitive  in  this  constantly  changing  world.  Having  a  formal  educational  program  also 
is  a  bedrock  for  creating  a  capacity  to  change.  People  grow  used  to  learning  new  ideas 
and  procedures.  “One  of  the  most  salient  approaches  to  improving  our  health  delivery 
system  is  investing  in  people”  (Johnson,  2001). 

Johnson  says  there  is  a  difference  between  training  and  education,  although  in 
most  organizations  the  terms  are  used  interchangeably.  For  him,  training  primarily 
focuses  on  the  acquisition  of  knowledge,  skills,  and  abilities.  Knowledge  is  a  byproduct 
of  both  remembering  and  understanding  information.  Skills  are  general  capacities  to 
perform  a  task  or  set  of  tasks,  often  gained  through  experience.  Abilities  are  capabilities 
to  perform  based  on  experience,  social  or  physical  conditioning  or  heredity. 

Education  is  the  development  of  general  knowledge  related  to  a  profession  but  not 
necessarily  designed  for  a  specific  position  within  that  profession.  The  introduction  of  a 
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new  proeess  or  system  would  require  both  training  and  education  depending  on  what  job 
a  person  performs  in  the  organization. 

Eight  training  principles,  forming  a  training  cycle,  are  discussed  by  Johnson. 

1 .  Identify  the  types  of  individual  learning  strengths  and  problems  and  tailor 
training  around  them. 

2.  Align  learning  objectives  to  organizational  goals. 

3.  Clearly  define  program  goals  and  objectives  at  the  start. 

4.  Actively  engage  the  trainee  to  maximize  attention,  expectations,  and  memory. 

5.  Use  a  systematic,  logically  connected  sequencing  of  learning  activities  so  that 
trainees  can  master  lower  levels  of  learning  before  moving  onto  higher  levels. 

6.  Use  a  variety  of  training  methods. 

7.  Use  realistic  job  relevant  material. 

8.  Allow  trainees  to  work  together  and  share  experiences. 

Additionally,  trainees  are  more  apt  to  remember  concepts,  terms,  skills,  etc.  if  they  hear 
or  say  them  more  than  once,  are  able  to  practice,  can  immediately  implement  them  in 
their  own  setting,  and  are  encouraged  and  rewarded  for  using  or  trying  the  new  method 
(Johnson,  2001). 

Another  concept  that  Johnson  discusses  is  called  “organizational  development”  as 
a  way  of  educating  employees  about  changes.  Its  techniques  include  survey  feedback, 
confrontational  meeting  and  coaching.  The  idea  is  to  work  through  the  natural  resistance 
to  change.  Success  is,  “in  part  a  result  of  [organizational  development’s]  philosophy  of 
participation  and  mutuality  and  its  belief  in  the  value  of  knowledge  at  all  levels  of  the 
organization.  [Organizational  development]  empowers  participants  in  the  change  process 
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by  involving  them  in  the  proeess  and  by  encouraging  their  commitment  to  the  desired 
change”  (Johnson,  2001).  Educating  employees,  exchanging  knowledge,  and  accepting 
feedback  are  all  ways  that  new  ideas  are  embraced  by  organizations. 

An  extremely  important  part  of  implementing  a  system  is  training  the  personnel 
who  will  operate  and  use  it.  For  systems  designed  and  implemented  in-house,  training 
plans  should  be  drawn  up  by  the  project  team,  and  team  members  should  take 
responsibility  for  coordinating  and  conducting  the  training  sessions.  If  systems  are 
purchased  from  commercial  firms,  the  company  will  usually  include  initial  training  as 
part  of  the  contract.  Training  is  critical  when  a  system  is  installed  and  should  include 
general  orientation  for  top  management  and  more  specific  training  for  first-line 
supervisors  and  direct  users  of  the  system.  There  has  been  considerable  difficulty  with 
many  information  systems  in  the  first  months  of  operation  because  operating  personnel 
were  not  properly  oriented  and  trained  in  advance  (Austin  and  Boxerman,  1998). 

Building  enthusiasm  and  buy  in  to  change  is  a  key  part  in  the  education  of  leaders. 
Patrick  Bettini  discusses  three  ways  that  this  is  done,  “First  Cut  Education,”  “Detailed 
Education,”  and  “Ongoing  Education.” 

First  Cut  Education  is  done  early  in  the  change  process  and  educates  key  leaders 
on  how  the  new  processes  will  work,  what  they  consist  of,  how  they  operate,  how  they 
will  be  able  to  manage  effectively,  and  what  will  be  required  to  implement  and  use  them 
properly.  Ideally,  these  newly  educated  leaders  will  become  enthusiastic  supporters  who 
will  assist  in  the  implementation  of  the  changes.  They  in  turn  will  brief  and  inform  their 
employees  on  what  the  system  is  about  and  why  it  is  needed,  preparing  the  workforce  to 
accept  the  new  system. 
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Next  comes  Detailed  Education.  This  technically  specific  training  is  provided  to 
all  people  involved  in  using  the  new  system.  The  object  is  to  provide  essential 
knowledge  in  all  of  the  areas  of  the  new  system,  such  as  scheduling,  inventory 
management,  billing,  etc.  When  personnel  are  educated  on  how  to  effectively  utilize  the 
new  system,  they  will  quickly  lose  their  resistance  to  the  changes  being  made,  allowing  it 
to  be  fully  integrated  into  the  organization’s  culture. 

Ongoing  Education  happens  as  the  system  is  being  installed  and  as  it  is  being 
used.  It  involves  a  continuing  effort  to  upgrade  the  staffs  awareness  of  and  skills  with 
the  system.  By  improving  performance  of  the  individual  tasks  being  done  with  the 
system,  the  overall  value  of  the  system  to  the  company  increases.  Ongoing  Education 
reinforces  initial  education  and  is  necessary  for  new  employees  and  employees  new  to 
their  jobs. 

Bettini  stresses  that  education,  at  all  levels,  is  the  key  to  accepting  change  and 
enabling  your  investment,  the  new  system,  to  be  effectively  utilized.  Training  and 
education  are  the  vehicles  that  make  implementation  of  change  successful  for  any 
organization  (Bettini,  1997). 

Implementing  Change 

Developing  an  effective  implementation  plan  is  as  important  to  an  organization 
as  is  developing  a  good  automated  information  system.  Brian  T.  Zimmer  feels  the  project 
must  be  broken  down  into  “manageable  chunks.”  People  must  be  assigned  responsibility 
for  these  chunks,  and  a  time  line  for  the  completion  of  tasks  must  be  created.  The 
training  portion  of  the  plan  needs  to  begin  as  soon  as  possible  and  run  simultaneously 
with  implementation.  Training  should  be  in  two  forms.  The  first  should  focus  on  basic 
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system  training  for  all  employees.  The  second  should  involve  simulating  the  technology 
under  various  business  conditions.  Many  companies  find  it  is  easy  to  buy  new 
technology  but  then  find  that  they  do  not  possess  the  necessary  skills  in-house  to 
configure  it  to  their  organization  and  train  their  personnel.  This  must  be  thought  out 
during  the  implementation-planning  process  (Zimmer,  1999). 

When  implementing  a  new  automated  information  system  (also  known  as 
“cutover”),  there  are,  according  to  Zimmer  and  Smith,  three  different  approaches  that  can 
be  used.  They  are  the  “Big  Bang,”  the  “Step  by  Step,”  and  the  “Parallel  Paths.” 

The  Big  Bang  approach  refers  to  implementation  at  a  predefined  changeover  date, 
when  all  of  the  old  machines  and  systems  are  turned  off  and  the  new  one  is  turned  on. 
This  approach  can  be  traumatic,  particularly  if  the  technology  being  implemented  is 
complex  or  far  reaching.  It  is  appropriate  in  disciplined  environments,  when  the  new 
system  is  simple,  or  where  existing  conditions  are  so  problematic  that  immediate  benefits 
must  be  realized  even  if  it  means  taking  great  risk. 

The  Step  by  Step  approach  is  taken  when  a  project  is  so  large  or  complex  that  it 
makes  sense  to  implement  it  in  steps.  This  approach  is  popular  in  organizations  that  are 
not  desperate  for  a  new  system  and  can  take  time  in  implementing  it  “to  bite  of  and  chew 
a  piece  at  a  time.”  The  down  side  of  this  approach  is  that  it  may  delay  the  benefits  of  the 
new  technology.  In  fact,  it  is  important  to  make  sure  that  the  project  is  not  equivalent  to 
and  endless  staircase  where  the  end  is  never  reached. 

The  Parallel  Path  approach  is  similar  to  the  Step  by  Step  approach  except  that  the 
old  and  new  technologies  run  in  tandem  until  the  new  technology  becomes  fully 
functional.  At  that  point,  the  old  technology  is  turned  off  and  removed.  While  a  very 
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safe  approaeh,  its  major  drawback  is  the  amount  of  resources  it  takes  to  maintain  two 
different  systems  at  the  same  time.  Few  organizations  can  afford  it  (Zimmer,  1998). 

This  approach  is  not  recommended  by  most  experts.  Because  as  Hutchins  succinctly 
explains,  “If  you  try  to  build  your  widget  the  new  way  while  allowing  the  old  way  to 
remain  in  place,  the  workers  will  find  a  way  to  let  you  think  they  are  using  the  new 
system  while  actually  using  the  old  one”  (Hutchins,  1999). 

The  number  and  seriousness  of  problems  that  managers  have  with  cutover  is 
usually  a  good  measure  of  the  type  of  job  done  in  development,  training  and  installation. 
The  fewer  problems  that  arise,  the  better  job  they  did  involving  the  entire  organization  in 
the  new  systems  creation  and  implementation  (Zimmer,  1999). 

Implementing  a  new  system  is  done  best  when  the  planning,  control,  and 
execution  are  accepted  by  the  senior  leaders  as  well  as  the  users  of  the  new  system.  The 
project’s  success  hinges  on  the  people  involved,  as  well  as  on  the  new  technology  to  be 
utilized. 

Deployment  of  DMLSS  to  MACH 

DMLSS  Release  3.0  includes  the  Stockroom  and  Readiness  Inventory 
Management,  Equipment  and  Technology  Management,  and  Assembly  Management 
modules.  Hardware  and  software  license  allocations  are  based  on  a  site-sizing  algorithm 
that  takes  into  account  clinic  visits  and  expenditure  of  medical  supply  dollars.  With  the 
deployment  of  Release  3.0,  old  systems  (TAMMIS  and  Army  Medical  Department 
Property  Accountability  System  (AMEDDPAS))  were  shut  down  and  DMEESS  became 
the  sole  medical  logistics  system  for  MACH. 
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The  guiding  principle  for  a  successful  DMLSS  3.0  release  is  for  each  service  to 
accept  responsibility  for  its  implementation  and  sustainment.  Responsibilities  are  as 
follows:  the  Program  Office  purchases  the  hardware  and  software  and  sends  contractors 
to  install  the  new  equipment,  the  JMLFDC  staff  monitors  the  system  and  works  to  fix  any 
deficiencies,  and  the  United  States  Army  Medical  Information  System  Support  Agency 
(USAMISSA)  provides  one  of  its  two  deployment  teams  to  instruct  the  staff  on  the 
system.  Each  team  is  led  by  a  captain  and  has  subject  matter  expert  non-commissioned 
officers  that  act  as  instructors.  USAMISSA  also  provides  a  Help  Desk  for  sites  to  call  for 
assistance  and  to  voice  concerns  (Duvall,  2003). 

The  following  information  was  obtained  through  interviews  with  MACH 
logistical  staff  members  (Ms.  Smith,  Mr.  Leidy,  SSG  Andreis  and  CPT  Peacock)  and 
from  an  after  action  review  written  by  personnel  of  the  Logistics  Division.  It  is  a 
description  of  the  process  used  to  deploy  Release  3.0  to  MACH. 

In  2000,  the  Commander  and  Chief  of  Logistics  volunteered  MACH  to  be  the 
Army  test  site  for  Release  3.0.  The  deployment  took  place  from  18  June  to  5  July  2001. 
The  USAMISSA  teams  were  not  yet  functioning,  so  a  team  from  JMLLDC  was  created 
to  conduct  the  deployment.  Preparations  for  the  deployment  began  during  the  winter  of 
2001 .  The  Chief  of  Supply  and  Acquisition  was  sent  to  Tyndall  Air  Lorce,  Llorida  base 
to  observe  a  DMLSS  Release  3.0  in  operation.  Although  MACH  had  DMLSS  Release 
1.0  and  2.0,  they  were  only  being  used  in  the  operating  room  and  pharmacy  and  then  only 
to  access  the  supply  catalog. 

A  site  survey  was  done  approximately  6  months  prior  to  the  deployment.  During 
the  survey,  a  schematic  was  done  detailing  where  computers,  printers,  and  drops  were 
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loeated  and  where  new  ones  had  to  be  installed.  This  was  also  the  time  where  release  3.0 
was  being  “sold”  to  the  staff  For  example,  a  medieal  maintenance  sergeant  major  from 
Medical  Command  came  to  brief  the  medical  maintenance  shop  on  the  benefits  of 
switching  to  DMLSS  and  briefings  were  conducted  by  the  site  survey  staff  on  the 
integrated  logistical  capabilities  of  DMLSS.  Nonetheless,  there  was  still  some  resistance 
by  people  who  had  used  other  systems,  such  as  TAMMIS,  for  many  years.  “ITl  retire 
before  I  learn  a  new  system”  was  what  one  long  time  employee  said. 

After  the  site  survey  was  conducted,  the  data  were  converted.  Old  stored  data 
were  reformatted  and  moved  from  the  current  system  to  the  new  one.  The  conversion 
was  ineffective  in  many  areas  since  the  JMLFDC  team  wasn’t  entirely  sure  of  what  was 
needed  from  the  old  TAMMIS  and  AMEDDPAS  systems  (the  historical  information  that 
the  new  system  would  need  to  order  supplies  and  track  property  wasn’t  completely 
transferred  over).  New  equipment  arrived  —  printers  for  barcodes,  hand  held  barcode 
readers,  and  computers.  Training  schedules  were  created  for  the  classroom  portion  of  the 
deployment  training.  Privilege  levels  within  the  DMLSS,  the  authorization  of  who  is 
allowed  to  do  what  in  the  system,  were  also  assigned  at  this  time.  In  addition,  it  was 
decided  that  the  two  classrooms  on  the  9*  floor  would  be  used  for  the  DMLSS  training. 

The  deployment  began  on  18  June  2001  and  lasted  for  3  weeks.  Week  1  was 
mainly  for  installing  the  new  equipment,  setting  up  the  rooms  for  training,  and  getting  the 
educational  database  functioning.  Week  2  was  for  classroom  instruction.  The  first  two 
days  of  classes  were  for  the  entire  Logistics  Division,  with  general  overviews  on  what 
DMLSS  could  do.  Since  the  instructors  had  only  two  classrooms  to  work  with,  the 
personnel  were  rotated  through  on  a  tight  schedule.  Most  people  did  not  attend  all 
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elasses,  but  only  those  that  pertained  to  their  specific  job.  Some  sections  (e.g.,  medical 
maintenance)  split  their  staffs,  half  went  to  class  in  the  morning,  half  in  the  afternoon. 
This  enabled  them  to  continue  providing  services  to  the  facility.  At  the  beginning  of 
Week  3,  the  old  systems  were  turned  off  and  DMLSS  was  activated — a  Big  Bang.  This 
week  was  devoted  to  on  the  job  training,  with  the  staff  trying  to  conduct  normal  business 
operations  using  DMLSS  and  the  deployment  team  there  to  coach  them  through  and 
correct  any  system  problems.  Each  of  the  interviewees  (Andreis;  Leidy;  Smith,  2003  and 
Peacock,  2002)  stated  this  was  the  most  beneficial  part  of  the  deployment  process.  After 
the  deployment  team  left,  the  personnel  at  the  DMLSS  Help  Desk  responded  to  numerous 
inquiries  and  greatly  assisted  the  staff  in  making  DMLSS  fully  functional. 

Many  issues,  discussed  more  fully  in  Appendix  A,  came  up  during  the  3 -week 
deployment  and  in  the  months  that  followed.  Since  this  was  a  test  site,  problems  were  to 
be  expected.  The  lessons  learned  here,  and  at  the  next  site  to  have  DMLSS  3.0 
deployment,  Brooke  Army  Medical  Center  in  San  Antonio,  Texas,  will  enable  future 
deployments  to  go  much  more  smoothly  and  efficiently. 

Discussion 

How  did  the  deployment  at  MACH  compare  with  what  the  experts  described? 
Were  the  employees  mentally  prepared  for  the  change?  Was  the  training  properly 
conducted?  Was  the  implementation  well  planned  and  executed? 

Anticipating  Change 

The  staff  at  MACH  knew  that  change  was  coming  years  before  it  happened.  This 
was  not  planned  but  was  a  side  effect  of  the  long  development  and  piecemeal  deployment 
of  different  releases.  Since  no  downsizing  of  the  workforce  was  projected,  the  employees 
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did  not  fear  that  the  new  system  was  being  brought  in  to  reduee  staff  There  was 
resistance  to  the  change  since  many  employees  had  used  TAMMIS  and  AMEDDPAS  for 
over  a  decade  and  did  not  want  to  change  their  routines.  The  Logistics  Division  had  two 
champions  of  the  new  DMLSS  system  who  helped  overcome  such  resistance.  One  was 
the  Chief  of  Logistics,  who  volunteered  MACH  as  the  test  site,  and  the  other  was  the 
Chief  of  Supply  and  Acquisition,  who  was  sent  to  see  a  fully  operational  system  at  the 
hospital  at  Tyndall  Air  Lorce  Base.  These  two  officers  became  the  driving  force  for 
implementation.  They  briefed  and  explained  the  new  system  to  their  staffs  and 
demonstrated  what  it  could  do  and  how  it  would  improve  the  division.  Subject  matter 
experts,  such  as  the  sergeant  major  from  MLDCOM,  came  in  and  reinforced  their 
message.  The  hospital  leadership  was  dedicated  to  the  change  and  sufficient  resources 
were  provided  to  make  the  change  as  smooth  as  possible.  Larly  focus  on  mentally 
preparing  the  workforce  enabled  a  rapid  acceptance  of  DMLSS  and  an  effective 
deployment. 

Moncrief  passed  through  the  four  stages  of  change  (Awareness,  Identification, 
Implementation,  and  Institutionalization)  described  by  Shortell  and  Kaluzny.  The  need 
was  recognized  (the  Awareness  stage)  not  by  MACH  staff  but  by  the  senior  medical 
logistics  staffs  in  the  three  services  who  sought  to  have  one  all  encompassing  logistics 
system  for  DoD.  The  MACH  leadership  saw  it  as  good  for  the  organization,  and, 
consequently,  worked  to  complete  the  fielding  of  the  system  as  soon  as  possible. 
Identification  was  done  by  the  Chief  of  Logistics  when  he  recognized  the  shortcomings 
of  having  multiple  logistics  systems  in  his  facility.  Simplification  and  increased 
efficiency  would  come  with  one  system  that  would  encompass  all  areas  of  logistics  in 
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one.  Implementation  will  be  talked  about  more  fully  in  following  paragraphs,  but  it  was 
done  well,  especially  considering  that  MACH  was  the  first  organization  in  the  Army  to 
receive  release  3.0.  Institutionalization  is  ongoing,  but  the  staff  now  has  a  strong 
understanding  of  the  system  and  is  passing  that  knowledge  onto  new  employees.  This 
makes  DMLSS  part  of  the  culture  and  no  longer  the  “new”  system,  but  the  regular  and 
accepted  system  that  makes  it  possible  for  employees  to  do  their  jobs. 

Training  For  Change 

Preparing  the  workforce  to  utilize  a  new  computer  system  is  80%  of  what  makes  a 
system’s  deployment  successful.  Since  the  training  that  took  place  at  MACH  was  the 
first  for  the  entire  Army,  it  was  not  as  good  as  it  could  have  been,  but  it  was  effective 
enough  that  the  system  users  were  able  to  do  their  jobs  and  quickly  become  experts  with 
Release  3.0. 

Bettini’s  First  Cut  Education,  Detailed  Education,  and  Ongoing  Education  were 
all  utilized  in  the  implementation.  Eirst  Cut  Education  was  done  when  actions  were  taken 
to  educate  the  leadership  of  the  division  on  DMESS  (e.g.,  sending  the  Chief  of  Supply 
and  Acquisition  to  an  Air  Eorce  hospital  to  view  a  working  system)  and,  in  turn,  the 
leadership  briefed  their  staffs.  This  was  part  of  the  “selling”  of  the  system.  It  also  helped 
the  leadership  picture  what  the  end  state  needed  to  be  and  enhanced  their  planning  for  the 
implementation. 

Some  shortcomings  were  found  in  Detailed  Education.  In  week  2  of  the  MACH 
deployment,  classroom  instruction  was  given  to  the  staff  by  the  deployment  team.  In 
some  cases  the  wrong  people  were  sent  and  those  who  should  have  been  sent  were  not. 
This  stemmed  from  the  classes  not  being  tailored  to  the  practices  at  MACH.  The 
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instructors  needed  to  have  studied  the  business  practices  of  MACH  more  closely  to 
understand  what  staff  members  needed  what  instruction.  Also,  the  computers  used  for 
training  in  the  classrooms  needed  to  have  a  better  database  and  more  memory.  Their 
limitations  made  the  classes  ineffective  for  everything  but  the  introduction  of  modules. 
The  on-the-job  training  that  took  place  was  much  more  effective  than  were  the  classes.  It 
enabled  instructors  to  guide  employees  through  the  exact  steps  they  needed  to  conduct 
their  jobs.  More  than  once,  however,  problems  arose  with  the  system  forcing  instructors 
to  stop  teaching  to  make  corrections  with  the  database.  This  wasted  valuable  time. 

“Ongoing  Education”  is  being  done  informally  with  current  employees  instructing 
new  ones,  with  an  additional  visit  (in  January  2003)  by  the  USAMISSA  deployment  team 
whose  members  provided  instruction,  and  now  with  ad  hoc  DMLSS  classes  being 
provided  in  San  Antonio  by  USAMISSA  personnel.  Regularly  scheduled  courses  with 
set  curricula  are  being  developed.  When  these  are  completed,  new  employees  will 
receive  a  thorough  course  of  instruction  before  they  assume  their  duties. 

Education,  at  all  levels,  is  the  key  to  accepting  change  and  enabling  an 
investment,  like  the  DMLSS  system,  to  be  effectively  utilized.  Training  and  education 
were  the  vehicles  that  made  implementation  of  DMLSS  3.0  successful  at  MACH. 
Improvements  were  needed  but,  with  the  lessons  learned,  future  deployments  can  be  even 
more  effective. 

Implementing  Change 

Austin  and  Boxerman’s  phases  of  implementation  (equipment  acquisition, 
database  preparation,  system  testing)  give  a  guide  for  evaluating  the  MACH  deployment. 
The  DMLSS  system  was  provided  to  MACH  by  the  DMLSS  program  office,  along  with 
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additional  equipment  like  personal  eomputers,  barcode  printers,  hand  held  inventory 
terminals.  The  site  visit  done  by  the  deployment  team  led  to  the  creation  of  diagrams  of 
the  system  layout  for  the  facility  and  a  list  of  the  equipment  needed  by  MACH.  Any 
additional  local  area  network  drops  were  installed  prior  to  the  first  week  of  deployment 
and  the  new  equipment  was  installed  in  the  week  prior  to  the  beginning  of  training.  It 
was  a  good  plan  and  enabled  the  staff  to  train  and  function  effectively  once  the  new 
system  was  turned  on. 

Database  preparation  required  converting  data  files  from  TAMMIS  and  AMEDDPAS 
to  DMLSS  compatible  ones.  There  were  also  additional  data  files,  e.g.,  quality  assurance 
files,  that  had  to  be  added.  Since  there  were  over  10  years  of  data  files,  the  amount  of 
data  to  be  converted  was  large.  Time  should  have  been  spent  selecting  information  that 
would  be  needed  and  not  converting  “garbage”  files.  Overall,  the  conversion  went  well, 
though  additional  work  in  accessing  stored  information  had  to  be  done  during  the  actual 
deployment. 

The  entire  system  was  tested  once  it  was  turned  on  and  the  old  systems  were  turned 
off.  With  the  deployment  team  and  staff  working  together,  problem  identification  was 
quick  and  could  be  documented  or  corrected  immediately.  Testing  the  system  in  this  way 
did  take  away  from  training  when  the  deployment  team  had  to  leave  students  to  work  out 
problems. 

The  switch  over  to  the  new  system  does  not  fit  neatly  into  one  of  the  approaches 
(Big  Bang,  Step  by  Step,  and  Parallel  Path)  discussed  by  Zimmer  and  Smith.  The 
DMLSS  deployment  had  features  of  all  of  them.  The  DMLSS  deployments  extended 
over  several  years  and  might  be  considered  to  have  been  Step  by  Step.  Release  1.0  and 
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2.0  were  already  in  plaee  at  MACH,  but  once  3.0  was  operational,  all  the  old  systems 
were  finally  permanently  cut  off,  a  Big  Bang  action.  The  deployment  was  also  like  a 
Parallel  Path  approach  because  Releases  1.0  and  2.0  were  in  place  for  years  while 
TAMMIS  and  AMEDDPAS  were  also  being  utilized.  Because  the  old  business  practices 
could  still  be  used,  early  DMLSS  releases  were  ineffective.  This  experience  probably 
accounted  for  the  final  Big  Bang  implementation. 

Considered  in  its  entirety,  the  deployment  process  was  effective.  It  got  new 
technology  into  the  field  and  available  for  use  in  a  timely  manner  and  with  a  trained 
workforce  capable  of  utilizing  the  system’s  full  potential. 

Developing  the  Formal  Deployment  Plan 

In  December  2001,  the  DMLSS  Program  in  Palls  Church,  Virginia,  released  its 
DMLSS  Site  Implementation  and  Pielding  Plan.  The  document  deals  with  installation 
and  implementation  of  Release  3.0  to  MTPs.  Each  of  the  steps  in  the  plan  was  either 
tested  at  MACH  or  discovered  due  to  a  deficiency  found  in  the  MACH  deployment. 
Without  the  experiences  gained  at  the  MACH  test  site,  improvements  could  not  have 
been  made  to  the  process  and  this  new  plan  could  not  have  been  developed  (Duvall, 
2003).  The  Implementation  Plan  is  presented  in  Appendix  B. 

Conclusion 

The  DMLSS  3.0  deployment  has  been  a  success,  not  only  for  MACH,  but  also  for 
the  Army  as  a  whole.  MACH  has  a  single  system  that  manages  logistics  throughout  its 
facility  (one  that  is  unparalleled  in  civilian  organizations),  and  the  Army  has  learned  a 
more  effective  way  to  deploy  its  new  system  to  the  rest  of  its  facilities.  While  the 
deployment  process  at  MACH  was  far  from  perfect,  each  mistake  added  to  the  base  of 
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knowledge  and  helped  improve  planning  for  future  deployments.  DMLSS  3.0  is  putting 
military  medieal  logistics  at  the  forefront  of  the  industry  in  the  2L*  century. 
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Appendix  A 

MACH  After  Action  Review^ 


Pre-Conversion 

Issue-  Road  to  Conversion  [C]  Checklist 

Discussion-  A  clear  timeline  and  assignment  of  responsibilities  would  make  preparation 
and  execution  considerably  smoother.  During  the  months  leading  up  to  conversion,  we 
knew  that  there  were  things  that  we  should  be  doing  to  prepare,  but  did  not  know  what  or 
how.  We  also  did  not  know  who  was  supposed  to  do  the  work. 

Recommendation-  The  MTF  should  be  provided  with  a  checklist,  at  least  2  months  from 
conversion,  that  lays  out  exactly  what  should  be  done  to  prepare.  Prioritize  the  list  into 
actions  that  must  be  taken  and  those  that  would  improve  the  system  but  are  not  a 
requirement.  It  should  establish  milestones  that  should  be  reached  in  the  time  period 
prior  to  the  team  arriving  on  site  (e.g.  C  -60  days  prior:  Identify  all  computer  systems 
that  will  be  operating  DMLSS  3.0).  These  milestones  should  be  related  to  those  that  the 
conversion  team  are  following  themselves  (e.g.  C  -45  days  prior:  Perform  Site  Survey 
Visit).  This  would  help  in  coordinating  fielding  preparation,  identifying  the  people  who 
are  involved  etc.  The  most  important  feature  of  this  would  be  to  plan  and  identify  actions 
that  should  be  taken  to  clean  up  data  in  the  legacy  systems. 

'  This  is  the  after  action  review  of  the  deployment  of  DMLSS  3.0  to  MACH.  It  was  prepared  by 
CPT  Michael  Peacock,  based  on  comments  by  the  Logistics  Division  staff  at  MACH  and  was  originally 
entitled  “DMLSS  3.0  Conversion,  After  Action  Review,  Stockroom  Inventory  Management  Module.”  The 


format  has  been  modified  slightly. 


Case  Study  of  the  DMLSS  Deployment  44 


Issue-  Data  Validation 

Discussion-  Over  the  years,  TAMMIS  has  accumulated  large  quantities  of  records  that 
are  no  longer  used.  The  multitude  of  garbage  records  creates  a  large  burden  on  the 
conversion,  validation  and  any  corrections  that  will  be  required.  With  DMLSS,  when 
you  delete  a  record,  it  remains  in  the  MTF  catalog,  it  just  doesn’t  appear  in  any  customer 
catalogs.  This  means  that  the  record  is  not  truly  deleted.  All  of  these  records  slow  down 
searches  and  cause  confusion. 

Recommendation-  The  MTF  needs  to  get  rid  of  all  of  the  garbage  data  in  the  Legacy 
system.  Time  also  needs  to  be  spent  cleaning  up  the  data  in  the  system.  This  clean  up 
should  go  beyond  the  actions  mandated  by  the  conversion  team.  The  MTF  should  begin 
reviewing  all  of  their  [sic]  stock  records,  customer  records  and  Sources  of  Supply  records 
at  least  3  months  prior  to  conversion.  The  focus  should  be  on  deleting  records  without 
recent  use  (a  record  not  used  within  the  last  2  years  is  a  reasonable  benchmark,  but 
consider  deleting  items  not  used  in  the  last  year).  By  deleting  these  records  before 
conversion,  the  MTF  will  make  post-conversion  validation  and  clean-up  considerably 
easier  to  handle.  Items  that  are  not  deleted  need  to  be  reviewed  for  correctness  and 
completeness.  The  conversion  team  should  identify,  by  Legacy  System  record  type, 
which  data  fields  will  be  transferred  into  the  corresponding  DMLSS  record.  The  MTF 
should  then,  at  a  minimum,  ensure  that  those  fields  are  complete  and  correct.  It  is  much 
easier  to  delete  a  record  and  build  it  as  needed  later  than  to  try  to  work  huge  lists  during 
post-conversion  clean  up. 

Cleaning  up  these  records  should  have  been  completed  prior  to  the  DMLSS  2.0 
fielding.  The  result  of  not  doing  it  was  that  all  of  the  junk  data  converted  into  the 
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DMLSS  database.  Since  this  is,  apparently,  the  same  database  used  for  3.0,  it  may 
require  deleting  the  records  from  both  TAMMIS  and  DMLSS  2.0  before  conversion. 
Some  method  of  doing  this  clean  up  should  be  developed  between  the  TAMMIS  and 
DMLSS  team,  and  it  should  require  as  little  work  on  the  MTF  as  possible. 

Issue-  Pre-conversion  Actions 

Discussion  -  The  site  survey/preparation  process  should  be  broadened.  Many  problems 
that  we  experienced  could  have  been  prepared  for  if  the  conversion  team  had  a  good 
understanding  of  our  business  processes. 

Recommendation-  Include  the  JMLFDC  subject  matter  experts  on  the  survey  team. 

These  people  should  find  out  exactly  what  each  person’s  daily  routine  consists  of,  what 
processes  or  systems  are  used  in  the  specific  MTF  etc.  This  will  allow  them  to  plan  for 
both  the  classroom  and  on-the-job  training  by  keeping  both  the  system  processes  and  the 
MTF  business  processes  in  mind. 

The  survey  team  should  also  have  the  capability  to  test  the  hardware  and 
infrastructure  of  the  facility.  In  this  way  they  will  be  able  to  identify  issues  with  the  RF 
LAN  [Radio  Frequency  Local  Area  Network],  IP  Subnets  [Internet  Protocol 
Subnetworks],  required  LAN  drops  etc. 

Issue-  MTF  Preparation 

Discussion-  The  MTF  did  not  have  clear  guidance  or  a  set  of  duties  in  preparing  for  the 
conversion.  Some  actions  were  taken  on  our  own  which  paid  off.  There  are  other  actions 
that,  in  hindsight,  should  have  been  taken. 
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Recommendation-  The  following  actions  should  be  taken  prior  to  conversion: 

a.  100%  Inventory-  This  painful  process  paid  off  by  ensuring  that  the  on-hand 
quantities  and  values  carried  over  were  as  correct  as  possible.  It  also  relaxes  the  learning 
curve  by  eliminating  several  more  processes  that  must  be  mastered  immediately.  As  our 
yearly  inventory  was  approaching,  we  decided  to  conduct  it  in  TAMMIS,  because  we 
were  already  familiar  with  it. 

b.  Begin  using  the  .  .  .  handheld  terminals  [HHT]  for  several  months  before 
conversion.  Becoming  familiar  with  the  HHTs  and  the  RF  [radio  frequency]  controller 
issues  used  in  inventory  management  ahead  of  time  will  reduce  training  requirements  as 
well. 

c.  There  is  a  change  to  the  Unit  of  Issue/Unit  of  Measure  methods  in  DMLSS 
3.0.  This  change  requires  the  item  managers  to  verify  and  correct  conversion  factors  in 
each  catalog  record.  Not  doing  so  will  create  inventory  and  Prime  Vendor  problems. 
MTFs  should  begin  combining  the  Unit  of  Issue/Unit  of  Measure  records  at  least  1  month 
from  conversion,  if  possible.  This  will  prevent  the  item  managers  from  having  to  clean 
everything  up  immediately  after  conversion. 

d.  Prior  to  conversion,  the  MTF  should  set  up  an  informal,  internal  training 
session.  Bring  all  of  the  branch  personnel  together  and  show  them  the  system,  what  it 
looks  like,  what  changes  have  been  made,  what  it  does  etc.,  just  to  familiarize  them  with 
what  to  expect.  This  will  help  the  new  users  prepare  themselves  for  the  training. 

e.  Get  access  to  the  trial  conversions  of  your  database  a  couple  weeks  prior  to  the 
actual  conversion.  Have  the  item  managers  look  through  records  for  a  few  minutes  every 
day.  They  may  be  able  to  identify  problems  like  vendor  number  errors,  lost  data  etc. 
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f  Coordinate  a  visit  to  the  site  of  the  previous  fielding  in  order  to  get  an  idea  of 
what  the  system  does.  Bring  key  people. 

g.  Ensure  that  the  Prime  Vendor  is  very  involved  in  your  conversion.  Try  to 
ensure  that  their  people  most  knowledgeable  with  your  account  are  available  during  this 
time  period. 

Week  1  -  Computer  Training 

Issue-  Ensuring  that  the  right  people  go  to  the  right  class. 

Discussion-  Even  though  both  the  MTE  and  JMEFDC  team  tried  to  exchange  duty 
descriptions  and  class  itinerary/focus  [,  the]  assignment  of  which  classes  each  person 
needed  to  attend  is  not  a  solid  process  yet.  Based  on  the  daily  duties  and  class 
descriptions  provided,  many  people  were  assigned  to  classes  that  they  did  not  need,  or, 
more  importantly,  missed  classes  that  they  did  need.  The  bulk  of  this  confusion  rests  in 
the  fact  that  the  instructors  did  not  know  how  this  particular  MTE  operates,  and  we  did 
not  know  how  the  system  operates. 

Recommendation-  As  discussed  previously,  having  a  functional  expert  visit  the  MTE  and 
learn  daily  duties  and  processes  will  provide  some  continuity  when  developing  the 
training  schedule.  Requirements  can  be  made  to  fulfill  the  functional  needs  of  the  users. 
This  should  be  a  major  focus  of  the  site  survey. 

Week  2  &  3-  On  the  Job  Training  [OJT] 

Issue-  Maintaining  focus 

Discussion-  The  OJT  training  is,  by  far,  the  most  important  aspect  of  the  fielding.  It 
should  be  a  carefully  planned  event,  complete  with  training  schedule,  priorities  of  work, 
critical  tasks  etc.  The  team  worked  really  hard  during  this  2  weeks.  Unfortunately,  most 
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of  the  time  seemed  to  be  spent  fixing  conversion  problems  as  opposed  to  conducting  the 
kind  of  deskside  training  that  was  needed.  The  training  that  the  users  received  usually 
took  the  form  of  short,  quick  sessions  focused  on  answering  a  pointed  question.  The 
instructor  would  then  have  to  return  to  the  more  important  task  of  fixing  a  software  or 
hardware  problem.  This  is  not  to  say  that  the  training  was  not  worthwhile.  When  the 
team  left,  each  person  felt  that  they  knew  the  steps  needed  to  do  their  jobs.  However,  in 
the  following  week,  we  realized  that  we  were  not  familiar  enough  with  the  system  to 
handle  anything  other  than  the  simplest  of  procedures.  I  have  to  say  that  the  support  that 
we  have  received  telephonically  from  the  team  has  been  excellent. 

I  believe  the  main  contributor  to  this  distraction  is  a  lack  of  distinction  between 
instructors  and  fixers.  The  same  people  that  were  supposed  to  be  training,  were  also 
responsible  for  coordinating  for  changes,  fixes  and  crisis  control. 

At  the  same  time,  the  MTF  users  had  a  difficult  time  staying  focused  on  learning. 
After  being  shut  down  for  a  week,  there  were  a  lot  of  customers  coming  in  needing  help. 
These  interruptions  were  tough  on  the  people  trying  to  learn. 

Recommendation-  What  should  occur  is  a  slow,  repetitive  teaching  method  that  builds  in 
complexity  according  to  the  abilities  of  the  student.  The  instructor  needs  to  remain  with 
the  student  until  all  functions  have  been  explained.  They  should  have  the  time  to  teach 
the  whole  process,  and  action/reaction  of  the  system,  not  just  the  step-by-step  procedures. 
In  order  to  accomplish  this,  a  line  should  be  established  between  the  roles  of  the  team 
members.  Isolate  instructors  from  the  requirements  to  deal  with  problems.  This  may 
require  more  functional  experts  on  the  SRIM/CAIM  [Stock  Room  Inventory 
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Management/Customer  Area  Inventory  Management]  proeesses.  It  may  also  require 
more  time  on  station. 

Depending  on  the  MTF,  they  may  want  to  eonsider  going  to  limited  eustomer 
hours  during  this  time  period.  Having  distraetion  free  training  time  set  aside  will  help  the 
students. 

Issue-  Customer  Support  for  the  Web  (CSW)  Training 

Diseussion-  This  module  basically  replaces  Reorder  Lists  and  Credit  Card  request  forms. 
Although  the  CSW  module  is  available  in  version  2.03,  we  never  had  a  real  good 
understanding  of  how  it  works  and  how  to  incorporate  it  into  the  business.  This  was  still 
true  when  the  fielding  team  arrived  and  began  training.  The  result  was  that  the  training 
classes  set  aside  for  this  module  were  mostly  empty. 

Recommendation-  The  CSW  portion  of  the  training  should  be  planned  better  all  around, 
but  mostly  by  the  MTF.  The  MTF  needs  to  learn  the  functionality  of  the  module  and  how 
it  will  fit  into  their  supply  system  before  the  fielding.  Develop  a  plan  on  how  to  utilize  it 
and  where,  then  make  it  mandatory  for  the  affected  customers  to  attend  the  training.  At 
the  same  time,  the  MTF  and  fielding  team  should  coordinate,  as  one  of  their  critical  tasks, 
to  have  the  systems  put  in  place,  with  customers  loaded,  before  the  end  of  the  second 
week  of  training;  that  will  allow  time  for  the  fielding  team  to  provide  follow-up  training. 
Data  Conversion 
Issue-  Record  Overload 

Discussion-  When  the  system  information  was  converted,  it  generated  hundreds  of  new 
records  that  required  action  in  the  Pending  Actions  Inbox.  For  instance,  apparently  the 
entire  QA  [Quality  Assurance]  Message  database  from  USAMMA  [United  States  Army 
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Medieal  Materiel  Agency]  is  dumped  into  the  system.  DMLSS  will  check  all  On-Hand 
records  against  QA  Messages  to  see  if  any  match.  Those  that  do  match  must  be 
processed,  forwarded  to  the  areas  that  the  items  are  stored  etc.  Those  without  matches 
must  be  individually  worked  by  typing  in  a  completion  date.  Working  all  of  these  lists 
requires  a  lot  of  manpower.  Other  lists  like  this  are  the  new  MTF  Catalog  Items  and  the 
MTF  Catalog  Item  changes.  Both  of  these  can  consist  of  several  hundred  records  that 
must  be  individually  worked. 

Recommendation-  Every  effort  needs  to  be  made  to  clear  all  of  these  records  without 
having  to  review  and  alter  each  one.  For  instance,  build  a  script  that  will  complete  all 
QA  messages  with  no  on-hand  quantities,  or  approve  all  catalog  record  changes  caused 
by  UDR  [Universal  Data  Repository]  updates  and  other  acceptable  reasons.  There  is 
enough  data  clean-up  to  worry  about  without  creating  more. 

System  Issues 
Issue-  Clean  Up 

Discussion-  The  conversion  caused  several  unexpected  issues  that  had  to  be  worked  or 
are  still  in  progress. 

Recommendation-  Be  aware  of  the  following  issues: 

-  Many  Prime  Vendor  numbers  did  not  convert  properly.  The  Vendor  Number 
field  in  some  of  the  records  had  a  garbage  number  (the  number  that  does  not  match 
anything),  [and]  some  had  incomplete  numbers.  Item  Managers  must  validate  for 
accuracy  each  record  before  sending  the  first  order. 
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-  Manufaeturers  Numbers  did  not  transfer  correetly.  This  affected  the  credit  card 
sources.  Also,  none  of  the  source  telephone  numbers  or  account  numbers  were 
transferred. 

-  Not  all  locations  were  transferred  correctly.  Some  were  set  to  a  default  of 
“None”. 

-  Ensure  that  all  Standing  Order  contracts  are  assigned  a  current  FY  Document 
Number.  If  it  is  assigned  a  number  from  the  previous  FY,  DMFSS  will  not  allow  an 
increase  in  available  funds.  In  the  past,  we  prepared  the  subsequent  FY  contracts  before 
the  end  of  the  current  FY  pending  authorization  of  funds.  Therefore  it  was  assigned  a 
current  FY  Doc  Num. 

The  conversion  somehow  created  a  “Default”  location  on  all  Customer  Catalogs 
for  one  customer.  This  location  was  assigned  leveling  and  on-hand  balances. 

Issue-  Complexity 

Discussipn-The  first  impression  by  the  users  is  that  the  system  is  very  complex.  There 
are  many  more  steps  to  complete  simple  processes.  Too  many  steps  are  dependent  on 
something  else  occurring  first.  There  is  too  much  jumping  around  from  one  screen  to 
another  in  order  to  follow  and  complete  the  steps  in  the  required  order.  Another 
complaint  is  that  it  generates  more  paper  than  TAMMIS. 

Recommendation-  Much  of  the  perception  of  complexity  may  be  a  result  of  unfamiliarity 
with  the  system.  Some  of  it  may  be  related  to  the  linking  of  information  fields  discussed 
previously.  .  .  . 
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Issue-  RF  LAN 

Discussion-  The  RF  LAN  in  this  facility  was  not  functioning  properly  with  the  DMLSS 
software,  not  sure  if  it  is  a  hardware  or  software  problem.  The  conversion  team 
attempted  to  fix  it,  but  was  not  familiar  enough  with  the  system. 

Recommendation-  Someone  should  check  the  system  prior  to  conversion,  or  have 
someone  available  who  can  fix  problems.  The  RF  capabilities  should  be  demonstrated 
and  operational  prior  to  the  end  of  the  OJT. 

Hardware/  Network  Issues 

Issue-  Coordination  with  IMD  [Information  Management  Division] 

Discussion-  The  fielding,  from  a  Network  Administrators  point  of  view,  was  very 
reactive.  There  were  a  multitude  of  last  minute  issues  that  could  have  been  taken  care  of 
prior  to  conversion.  Some  examples: 

-  Need  for  additional  IP  addresses  for  unplanned  equipment  or  requirements. 

-  Installation  of  additional  software,  TCP  [Transfer  Control  Protocol]  /IP 
[Internet  Protocol]  Drivers,  hardware. 

-  Confusion  between  the  requirements  for  Static  vs  DHCP  [Dynamic  Host 
Configuration  Protocol]  IP  addresses. 

-  Printer  drivers  finding  their  way  through  Subnets. 

These  last  minute  details  created  a  lot  of  frustration  and  held  up  a  lot  of  work 
unnecessarily. 

Recommendation-  The  DMLSS  team  should  assign  2-3  knowledgeable  people  to  take 
care  of  issues  like  those  above.  The  team  should  coordinate  for  those  individuals  to  be 


assigned  System  Administrator  rights. 
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The  JMLFDC  team  requested  that  they  be  assigned  these  rights,  but  because  of 
network  security  regulations,  the  request  has  to  be  routed  through  to  the  correct  approval 
authority,  this  will  take  time.  It  is  in  the  best  interests  of  both  the  DMLSS  team  and  the 
MTF  Information  Management  Division  to  coordinate  for  this  approval  well  ahead  of  the 
scheduled  conversion  dates.  The  best  course  of  action  may  be  for  a  blanket  approval  to 
be  granted  at  MEDCOM,  and  sent  to  all  MTFs. 

Issue-  CPU  [Central  Processing  Unit]  Requirements 

Discussion-  When  assessing  the  capabilities  of  the  CPUs  within  the  MTF,  the  computers 
in  the  training  room  were  overlooked.  Two  systems  did  not  meet  the  minimum 
requirements.  This  resulted  in  a  last  minute  change  to  the  training  plan. 
Recommendation-  Ensure  that  all  system  are  included  in  the  hardware  review.  Re¬ 
evaluate  the  minimum  system  requirements  for  DMLSS  Users  and  Training  room 
systems.  200Mhz  [Mega  Hertz]  with  64MB  [Mega  Bites]  RAM  [Random  Access 
Memory]  will  run  the  program,  but  not  very  well.  Especially  when  trying  to  open  a 
report  or  conducting  catalog  searches. 
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Appendix  B 

DMLSS  Finaneial  Issues^ 

[There  were  multiple  issues  that  rose  from  DMLSS  finaneial  transactions. 
Following  is  are  the  major  issues  that  existed  with  the  configuration  of  the  financial 
interfaces.] 

Summary  Financial  Transactions  (Identified:  Aug  2001) 

DMLSS  uses  a  financial  logic  that  summarizes  all  financial  obligations  occurring  for 
each  APC  [Account  Processing  Code],  during  a  daily  cycle.  It  recognizes  all  transactions 
for  that  APC,  rolls  up  the  total  dollar  values,  and  will  send  them  out  as  a  summary 
transaction  under  the  last  document  number  in  the  series.  The  main  issue  is  that  the 
individual  or  root  obligations  are  not  accounted  for.  Only  the  last  document  number,  the 
summary  obligation,  will  appear,  and  that  will  be  for  a  dollar  amount  that  exceeds  the 
amount  of  the  disbursement  generated  by  DFAS,  based  off  of  the  vendors  electronic 
invoices.  At  the  same  time,  the  other  document  numbers  will  appear  in  the  .  .  .  [finance 
system]  as  disbursements,  but  will  not  match  up  with  an  obligation  under  the  same 
document  number. 

Element  of  Resource  [EOR]  (Identified:  Sep  2001) 

Obligations  are  not  being  allocated  to  the  correct  EOR,  31xx  (Equipment),  for  equipment 
items.  Originally  this  was  thought  that  involve  just  credit  card  purchases,  but  it  has  been 
found  to  effect  every  equipment  purchase.  When  the  Due-ins  are  created,  an  obligation 

2 

This  is  the  financial  after  action  review  of  the  deployment  of  DMLSS  3.0  to  MACH.  It  was 
prepared  by  CPT  Michael  Peacock,  based  on  comments  by  the  Logistics  Division  staff  at  MACH  and  was 
originally  entitled  “Information  Paper.”  The  format  has  been  modified  slightly. 
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goes  out  under  the  S570  (LOG  FUND)  aecount  with  a  26ER  .  .  .  FOR.  When  the  item 
is  reeeived,  cost  reallocations  are  supposed  to  be  sent  which  will  move  the  obligation  to 
the  customers  account  and  change  the  FOR  to  31XX.  As  far  as  the  local  staff  can 
determine,  no  obligation  has  been  reallocated  to  the  customers  APC  under  the  31xx  FOR. 
After  further  research,  it  has  been  found  that  two  obligations  have  been  sent  to  the  .  .  . 
[finance  system],  one  for  26FR/S570,  and  the  other  for  31FJ/S570.  Apparently,  the 
system  is  double-obligating  the  FOG  Fund  account. 

Catalogue  Prices  (Identified:  NOV  2001) 

A  code  problem  of  some  kind  is  preventing  DMFSS  from  properly  picking  up  price 
changes  that  are  sent  to  the  system  whenever  a  log  in  occurs.  DMFSS  is  receiving  the 
price  changes  sent  by  the  vendors,  but  is  apparently  using  an  old  price  when  sending  out 
its  obligations  to  DFAS.  This  issue  is  being  worked  by  the  DMFSS  team,  and  should  be 
nearing  completion. 

[The  team  at  JMFFDC  that  wrote  DMFSS  attempted  to  include  each  of  the  three 
Services  business  practices  in  the  program.  The  Army  practices  were  not  fully 
understood  and  therefore  problems  arose  once  DMLSS  was  implemented.  Since  August 
2001,  numerous  “patches”  or  corrections  in  the  program  code  have  been  made.  As  of 
January  2001,  these  patches  have  corrected  the  shortcomings.] 
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The  DMLSS  Site  Implementation  and  Fielding  Plan,  Seetion  4: 
Implementation  and  Fielding  Tasks^ 

4.1  Site  Preparation 

Preparing  the  site  for  Release  3.0  deployment  begins  approximately  5  months 
before  site  activation.  During  site  preparation,  the  DMLSS  deployment  team  works  with 
the  Service  deployment  teamwork  to  inform  site  personnel  of  all  pertinent  aspects  of 
Release  3.0.  Deployment  teams  also  work  with  site  personnel  to  identify  and  perform  the 
activities  required  to  prepare  the  site  to  receive  the  release. 


3 

The  DMLSS  Program  Office  published  this  DMLSS  Site  Implementation  and  Fielding  Plan  in 
December  2001.  It  spells  out,  step  by  step,  what  each  agency  and  command  needs  to  do  when  DMLSS  3.0 
is  deployed  to  an  MTF.  Please  note  that  the  format  (e.g.  indentation  of  paragraphs,  spacing,  etc.)  has  been 
modified  slightly. 

The  implementation  effort  begins  with  site  preparation  at  least  5  months  before  the  scheduled 
deployment.  During  these  5  months,  the  service  deployment  team  informs  site  personnel  of  DMLSS 
functions  and  explains  the  new  business  practices  that  will  effect  the  site’s  day-to-day  operation. 

Implementation  is  a  three  phase  effort.  First,  the  site  survey  determines  how  best  to  implement 
Release  3.0  components  at  the  site.  Second,  site  activation  includes  upgrading  the  server  and  client  PC 
hardware  and  software,  installing  Release  3.0  applications,  creating  a  production  database,  and  training  site 
personnel  to  use  DMLSS  properly.  Third,  post-activation  tasks  include  doing  a  quality  survey  and 


providing  follow-up  functional  support.  Each  of  these  parts  has  many  subcomponents  that  must  be 
accomplished  to  achieve  a  successful  implemenfation. 
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4.1.1  Educating  Site  Personnel 

The  Service  deployment  team  initially  contacts  the  site  no  later  that  5  months 
before  the  scheduled  activation,  providing  site  personnel  on  site  with  information  about 
Release  3.0  and  its  functionality. 

4.1.2  Converting  Site  Legacy  Data 

The  data  conversion  contractor  performs  an  initial  conversion  of  the  site’s  legacy 
data  to  assess  the  readiness  of  the  data  to  be  converted  to  the  DMLSS  Release  3.0 
database.  Potential  sources  of  legacy  data  include  TAMMIS  and  AMEDDPAS  .  .  .  After 
extracting  legacy  data  and  converting  the  data  to  a  Release  3.0  database,  the  contractor 
prepares  a  detailed  set  of  discrepancy  reports.  The  Service  deployment  team  reviews  the 
reports  and  prepares  to  brief  site  personnel  on  the  results  during  the  site  survey. 

4.1.3  Completing  the  Pre-Site  Survey  Questionnaire 

Before  the  pre-site  survey  conference  call,  the  site  completes  a  pre-site  survey 
questionnaire.  .  .  .  Because  the  questionnaire  focuses  on  technical  issues,  a 
representative  from  the  site’s  Information  Management  Office  (IMO)  is  most  suited  to 
complete  the  questionnaire. 

4.1.4  Conducting  the  Pre-Site  Survey  Conference  Call 

The  pre-site  survey  conference  call,  which  occurs  1  to  2  weeks  before  the  site 
survey,  serves  the  following  purposes:  [to]  establish  a  common  understanding  of  survey 
requirements  and  schedule  activities,  [and  to]  identify  major  issues  that  might  affect  the 
deployment.  The  pre-site  survey  conference  call  includes  the  following  participants: 
materiel  manager,  equipment  manager,  bio-medical  branch  chief,  resource  manager. 
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facility  manager,  IMO  .  .  .  ,  DMLSS  deployment  team  .  .  .  ,  [and  the]  service  deployment 
team. 


Site  personnel  who  plan  to  participate  in  the  pre-site  survey  conference  call 
should  review  the  DMLSS  Site  Implementation  and  Fielding  Plan.  .  .  . 

4.1.5  Conducting  Database  Conversion 

The  technical  contractor  and  database  conversion  contractor  convert  the  database 
in  2  to  3  days.  ...  At  a  minimum,  one  conversion  must  be  performed  during  site 
activation.  Additional  database  conversions  can  be  performed  at  any  time  between  the 
site  survey  and  the  site  activation  at  the  request  of  the  Service  deployment  team. 
Additional  conversions  can  determine  the  extent  to  which  legacy  system  data  must  be 
modified  to  obtain  a  valid,  operational  DMLSS  database  after  the  final  conversion. 

4.1.6  Conducting  the  Site  Survey 

The  site  survey  .  .  .  addresses  both  the  functional  and  technical  aspects  of 
implementation.  The  general  approach  to  the  survey  is  to  develop  a  plan  for  the 
functional  implementation,  collect  data  on  resources  available  in  the  target  areas,  and 
then  develop  a  fielding  strategy  based  on  the  functional  plan  and  the  available  resources. 
The  site  is  surveyed  3  to  5  months  before  the  scheduled  activation.  .  .  . 

The  survey  should  accomplish  the  following:  determine  how  Release  3.0 
components  are  best  implemented  at  the  site  from  a  functional  standpoint;  educate  site 
personnel  on  the  necessary  preparations  for  implementation  .  .  .  ;  identify  functional  and 
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teehnieal  issues  that  might  affect  the  implementation  and  identify  people  responsible  for 
following  up  on  the  issues  .  .  .  ;  and  identify  space  and  equipment  that  is  needed  to 
support  training  requirements,  including  the  location  of  the  training  server,  training 
rooms.  .  .  . 

4.1. 7  Completing  the  Memorandum  of  Understanding  or  Letter  of  Agreement 

After  the  site  survey,  the  Service  deployment  team  produces  a  memorandum  of 
understanding  (MOU)  or  letter  of  agreement  (LOA)  .  .  .  [which]  identifies  the 
responsibilities  of  the  site,  the  Service  team,  the  DMLSS  P[rogram]  M[anagement] 
0[ffice],  and  the  technical  contractor  during  the  pre-activation  and  activation  phases  of 
deployment.  The  MOU  or  LOA  is  submitted  to  the  site  for  signature  within  3  weeks  of 
the  conclusion  of  the  survey  .  .  .  [and  will  include]  the  Equipment  Placement  Form,  an 
Action  Item  List,  and  a  Target  Configuration  Spreadsheet. 

4.1.9  Identify  and  Assign  Roles  to  Site  Personnel 

[Before  activation,  the  MTF  identifies  roles  to  assign  to  those  who  will  be  using 
it.]  .  .  .  Although  the  DMFSS  server  upgrade  retains  user  accounts,  the  accounts  do  not 
receive  automatic  access  to  client  applications.  Administrators  for  each  application  .  .  . 
need  to  assign  roles  and  inherent  access  privileges  to  users  before  they  start  using  the 
system.  Identifying  users  and  their  levels  of  privileges  before  the  activation  contributes 
to  the  efficiency  of  onsite  activation.  .  .  . 
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4.1.10  Certify  Site  Readiness 

The  Service  deployment  team  certifies  readiness  for  release  3.0  activation.  If, 
however,  the  site  is  not  progressing  satisfactorily  approximately  4  weeks  before 
activation,  the  Service  deployment  team  recommends  one  of  the  following  actions  to  the 
DMLSS  PMO:  proceeding  as  scheduled,  postponing  activation,  or  canceling  activation. 
The  DMLSS  Program  Manager  then  decides  which  action  to  take. 

4.1.11  Pre-Configuring  New  Equipment 

The  DMLSS  Program  [Office]  provides  new  PCs  [personal  computers],  printers 
.  .  .  [other]  equipment  to  support  deployment.  .  .  .  [Information  gathered  during  the  site 
survey]  determines  guidelines  that  the  site  survey  team  uses  to  identify  the  quantity  of 
equipment  provided  to  a  site  according  to  its  size  and  needs. 

4.2  Site  Activation 

During  site  activation,  the  .  .  .  deployment  teams,  in  conjunction  with  site 
personnel,  issue  DMLSS  Release  3.0  applications  to  site  personnel  according  to  their  job 
functions.  The  activation  includes  upgrading  the  server  and  target  client  .  .  .  software, 
installing  Release  3.0  applications  on  selected  client  PCs,  .  .  .  creating  a  production 
database,  and  training  site  personnel  to  use  the  applications. 

The  duration  of  the  site  activation  and  size  of  the  activation  team  varies 
depending  on  the  MTF  size.  The  target  duration  for  onsite  activation  is  3  weeks. 
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4.2.1  Facilities 

The  site  provides  a  work  area  for  the  activation  team.  The  work  area  should  be 
large  enough  to  accommodate  four  to  five  individuals  and  should  include  at  least  one 
network  drop,  a  table  or  desk,  and  a  telephone  that  can  be  used  to  call  external  numbers. 

4.2.2. 1  Coordinate  Site  Activation  Process 

Service  deployment  representatives  ensure  that .  .  .  [communication  between  the 
groups  involved  in  the  activations  remains  effective].  Standard  activities  include  a 
kickoff  meeting,  daily  status  meetings,  and  a  closeout  meeting.  At  a  minimum,  meetings 
are  attended  by  Service  deployment  representatives;  the  DMLSS  activation  team;  and  site 
points  of  contact  from  logistics,  facilities,  finance  and  systems.  Topics  discussed  at  the 
meetings  include  the  activity  schedule,  implementation  status,  and  open  issues. 

4. 2. 2. 2  Conduct  Final  Database  Conversion 

Going  live  with  Release  3.0  depends  on  successfully  converting  the  database.  .  .  . 
For  the  first  step  of  the  conversion  process— validating  the  MM  portion  of  the 
Release  3.0  database— the  Service  deployment  team  assists  site  personnel  with  printing 
new  shelf  bar  code  labels.  Site  personnel  then  distribute  and  post  the  labels  throughout 
the  MTF  before  going  live  with  the  M[ateriel]  M[anagement]  portion  of  the  database. 

4. 2. 2. 5  Prepare  for  and  Conduct  Training 

During  activation.  Service  deployment  representatives  bear  primary  responsibility 
for  training,  including  scheduling  and  instructing  the  courses.  Service  deployment 
representatives  also  assist  the  technical  contractor  in  setting  up  the  training  room 
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equipment.  The  teehnical  contraetor  installs  the  training  server  and  sets  up  and  breaks 
down  ...  the  training  areas.  The  site  provides  adequate  space  and  furniture  to  support 
training,  access  to  the  MTF  LAN  for  each  training  area,  and  IP  addresses  for  all  training- 
related  equipment  requiring  connection  to  the  LAN. 

[Activate  Client  Personal  Computers,  Install  Printers,  Grant  User  Privileges] 

[To  activate  the  PCs  with  DMLSS,  they  must  first  be  prepared  for  DMLSS 
installation  and  then  the  program  must  be  loaded  onto  the  harddrive.  The  contractor 
works  with  site  logistics  personnel  to  determine  the  site-preferred  approach  to  printing 
DMLSS  client-based  print  requests.  The  site  supports  printing  from  its  network  printers, 
and  the  technical  contractor  supports  printing  from  printers  hosted  on  the  DMLSS  server. 
To  save  time  during  activation,  site  personnel  should  have  their  user  roles  for  the  DMLSS 
system  determined  before  the  deployment  team  arrives.] 

4.3  Post  Activation 

[Two  weeks  after  activation,  local  personnel  complete  “a  quality  survey”  on  the 
release  3.0  implementation  process.  Follow-up  functional  support  and  on-site  training 
are  provided  by  the  service  deployment  team.  Training  at  Service-level  schools  is  also 
provided.  A  Help  Desk,  located  in  San  Antonio,  Texas,  provides  assistance  to  MTFs  24 
hours  a  day,  7  days  a  week.  There  will  be  monthly  catalog  updates  to  the  Universal  Data 
Repository  are  provided  through  the  DMLSS  System  Administration  Tool  that 
automatically  updates  user  systems  when  they  log  into  DMLSS  each  day.]  .  .  . 


